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[57] ABSTRACT 

An in-line trigger is a modular, compiled, template trigger, 
which defines a series of actions to be performed when an 
operation is applied to a body of data. The series of actions 
to be performed when an in-line trigger fires are compiled 
into machine language instructions that receive three kinds 
of parameters: trigger-type specific parameters, operational 
metadata, and operational data. Trigger-type specific param- 
eters are loaded into a section of run-time memory once for 
multiple firings of the same trigger. Operational metadata 
and operational data are loaded each time the trigger fires. 

30 Claims, 4 Drawing Sheets 
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IN-LINE TRIGGERS 

FIELD OF THE INVENTION 

The present invention relates to database systems and 
more particularly to techniques for automatically perform- 
ing a series of actions when an operation is applied to a body 
of data. 

BACKGROUND OF THE INVENTION 

In a database system, a trigger is an object that specifies 
a series of actions to be automatically performed when a 
specific event occurs. According to industry standards, 
events that cause triggers to be activated (or "fired") are 
DML (Data Manipulation Language) statements. Thus, trig- 
gers may be designed to fire when a row of a database table 
is updated, inserted, or deleted. Accordingly, an individual 
trigger is typically associated with one database table. 

The series of actions specified by a trigger is typically 
written as instructions in a high-level database language 
such as SQL and PL/SQL, an extension of SQL available 
from Oracle Corp. of Redwood Shores, Calif. In conform- 
ance with industry standards, these instructions must be able 
to access the data values of table columns corresponding to 
an affected row before the triggering DML statement was 
applied (the "old values") and after the modification was 
applied (the "new values"). 

Since triggers are objects, database customers can define, 
remove, and 'Store triggers within a database, and the data- 
base systenfkeeps track of which triggers have been defined 
for which table by storing that information as metadata in the 
cdata dictionary. Consequently, triggers enable database cus- 
tomers to implement additional functionality in their data- 
bases for such purposes as enforcement of business rules and 
security. 

For example, the owner of a financial database may 
require for an account table that no account can be opened 
with a negative balance. In this case, a database adminis- 
trator defines a trigger that fires when a row is inserted into 
the account table. The actions specified by the definition of 
the trigger would direct the database system to check the 
value of the balance column of the account table, and if the 
balance is negative, generate an error message. After the 
database administrator has stored the instructions for the 
trigger in the database, when a user or application creates a 
new row in the account table, the database system fires the 
trigger. When the trigger is fired, the database system loads 
the trigger instructions as indicated in the metadata for the 
account table and interprets those instructions. In this 
example, the instructions check the opening account balance 
and generate an error message when the balance is negative. 

Another use for triggers is data replication. Under certain 
conditions, it is desirable to store copies of a particular body 
of data, such as a table in a relational database, at multiple 
sites. If users are allowed to update the body of data at one 
site, the updates must be propagated to copies at other sites 
in order for the copies to remain consistent. The process of 
propagating changes is generally referred to as replication. 

Some databases implement replication by defining trig- 
gers when DML statements are executed, for example, when 
a user inserts, modifies, or deletes a row in a table. In 
response to such a firing event, a replication trigger performs 
a series of operations that ultimately results in the change 
being propagating to the replication sites. For example, a 
replication trigger may submit the modification to a job 
queue. A replicator process periodically inspects the job 
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queue for replications to perform, and upon finding jobs in 
the queue, performs those replications. In another example, 
a replication trigger can propagate changes to another site 
before the current transaction commits. In either example, 

5 the performance of the replication trigger impacts the per- 
formance of the user statement which inserted, modified, or 
deleted the row. 

The trigger definitions for replication can be created by 
the database system itself from parameters supplied by a 

!0 database administrator. These trigger-type specific param- 
eters define details about the replication, such as what kind 
of replication is requested, which table is to be replicated, 
and which columns of the table are to be replicated. Thus, a 
database administrator only has to submit the particular 

15 parameters of a replication through a user interface, and the 
database system itself generates the requisite trigger defini- 
tions from the parameters. 

Replication is one environment in which a single opera- 
tion from a user can cause the same kind of DML statement 

20 to be applied and, hence, the same trigger to fire, repeatedly 
for a large number of rows. In such environments, the 
disadvantages of conventional trigger implementations are 
especially evident. In specific, conventional trigger imple- 
mentations suffer in the areas of performance and memory 

25 usage. 

Conventionally, trigger instructions are written in a high- 
level language, which must be interpreted at a substantial 
performance cost. Accordingly, some database systems pro- 
vide a way for partially compiling or tokenizing those 

30 trigger instructions into "stored procedures." The trigger's 
processing environment, such as the run-time memory 
configuration, has to be initialized each time a conventional 
trigger is fired. For example, replication triggers employ a 
replication-specific parameter that specifies the site to which 

35 the changes are to be propagated. This parameter must be 
loaded into a configured section of memory each time the 
trigger is fired, although the parameter has a constant value 
for that trigger. As an another example, the trigger instruc- 
tions may need to have access to such DML statement 

40 metadata as the name of the table for which the trigger fired. 
Some database systems attempt to reduce the performance 
penalty of trigger parameters by hard-coding them into the 
trigger instructions as constants and literals. However, this 
approach results in trigger proliferation. In other words, 

45 since parameters are hard-coded, a trigger for each table 
must use a distinct sequence of instructions. Each trigger 
consumes much memory. If, for example, there are thou- 
sands of replicated tables, then there are thousands of 
triggers. Accordingly, trigger proliferation consumes much 

50 memory. Furthermore, proliferated triggers with hard-coded 
parameters cannot reuse the same run-time memory 
configuration, initialized by a similar trigger. Therefore, it is 
desirable to reduce the memory consumption caused by 
trigger proliferation. 

55 Another drawback to conventional triggers is that their 
instructions are stored in the database and are consequently 
open to intentional or accidental modification by users of the 
database system. If a user modifies a replication trigger, the 
database system can no longer guarantee correct perfor- 

60 mance of the data replication. The modified trigger instruc- 
tions may contain errors that prevent the replication or even 
corrupt other data in the database. Thus, there is a need for 
secure triggers. 

65 SUMMARY OF THE INVENTION 

Accordingly, one aspect of the invention is a method for 
automatically causing a series of actions to be performed 
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when an operation is applied to a body of data. The method 
includes the step of defining a trigger for firing when the 
operation is applied to the body of data. This trigger specifies 
the series of actions and trigger-type specific data. 

When the operation is applied to the body of data, the 5 
following steps are performed. The method has a step for 
determining whether there is a section of run- time memory 
associated with the operation. If there is no such section, 
then the operation is compiled into a compiled form and the 
trigger-type specific data is loaded into this run-time section. 10 
Id either case, the method comprises the step of loading 
operation metadata that describes the body of data and 
operational data that describes the effect of applying the 
operation. The method also includes steps for applying the 
operation to the body of data and causing the series of 15 
actions to be performed based on the trigger-type specific 
parameters, the operational metadata, and the operational 
data. 

Another aspect of the invention is a computer system 
comprising one or more modular compiled template triggers 20 
and a database kernel process. The database kernel process 
is configured to invoke one or more of the modular compiled 
template triggers in response to a database event, such as 
receiving a request to perform a data manipulation language 
(DML) operation on a body of data. 25 

Still other objects and advantages of the present invention 
will become readily apparent from the following detailed 
description, simply by way of illustration of the best mode 
contemplated of carrying out the invention. As will be 3Q 
realized, the invention is capable of other and different 
embodiments, and its severaJ details are capable of modifi- 
cations in various obvious respects, all without departing 
from the invention. Accordingly, the drawing and descrip- 
tion are to be regarded as illustrative in nature, and not as 35 
restrictive. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example, 
and not by way of limitation, in the figures of the accom- co 
panying drawings and in which like reference numerals refer 
to similar elements and in which: 

FIG. 1 is a block diagram of a computer system according 
to an embodiment of the invention. 

FIG. 2 is a flowchart illustrating the operation of adding 45 
an in-line trigger according to one aspect of the invention. 

FIG. 3 is a flowchart illustrating the operation of execut- 
ing an in-line trigger according to an embodiment of the 
present invention. 50 

FIG. 4 is a flowchart illustrating the operation of execut- 
ing an in-line trigger according to another embodiment of 
the present invention. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

A method and apparatus for automatically causing a series 
of actions to be performed when an operation is applied to 
a body of data are described. In the following description, 
for the purposes of explanation, numerous specific details 60 
are set forth in order to provide a thorough understanding of 
the present invention. It will be apparent, however, to one 
skilled in the art that the present invention may be practiced 
without these specific details. In other instances, well-known 
structures and devices are shown in block diagram form in 65 
order to avoid unnecessarily obscuring the present inven- 
tion. 
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Hardware Overview 

Referring to FIG. 1, it is a block diagram of a computer 
system 100 upon which an embodiment of the present 
invention can be implemented. Computer system 100 
includes a bus 101 or other communication mechanism for 
communicating information, and a processor 102 coupled 
with bus 101 for processing information. Computer system 
100 further comprises a random access memory (RAM) or 
other dynamic storage device 104 (referred to as main 
memory), coupled to bus 101 for storing information and 
instructions to be executed by processor 102. Main memory 
104 also may be used for storing temporary variables or 
other intermediate information during execution of instruc- 
tions by processor 102. Computer system 100 also com- 
prises a read only memory (ROM) and/or other static storage 
device 106 coupled to bus 101 for storing static information 
and instructions for processor 102. Data storage device 107 
is coupled to bus 101 for storing information and instruc- 
tions. 

A data storage device 107 such as a magnetic disk or 
optical disk and its corresponding disk drive can be coupled 
to computer system 100. Computer system 100 can also be 
coupled via bus 101 to a display device 121, such as a 
cathode ray tube (CR1), for displaying information to a 
computer user. Computer system 100 further includes a 
keyboard 122 and a cursor control 123, such as a mouse. 

The present invention is related to the use of computer 
system 100 to automatically cause a series of actions to be 
performed when an operation is applied. Accordingly, com- 
puter system 100 executes sequences of instructions con- 
tained in memory 104 in response to processor 102. Such 
instructions may be read into memory 104 from another 
computer-readable medium, such as data storage device 107. 
Execution of the sequences of instructions contained in 
memory 104 causes processor 102 to perform the process 
steps that will be described hereafter. In alternative 
embodiments, hard-wired circuitry may be used in place of 
or in combination with software instructions to implement 
the present invention. Thus, the present invention is not 
limited to any specific combination of hardware circuitry 
and software. 

In-line triggers 

An in-line trigger is an object that specifies a generic 
sequence of instructions, preferably linked into the database 
kernel as compiled code, which automatically executes 
when a specific event, such as a DML operation, occurs 
within a database. Unlike conventional triggers, in-line 
triggers are compiled directly into machine language so that 
the overhead of interpreting a high-level language, partially 
compiled code, or tokenized code is avoided. Therefore, 
in-line triggers have a significant performance improvement 
over prior types of triggers. 

Since in-line triggers rely on generic, compiled functions 
for performing a series of actions, their operating parameters 
are not hard-coded within their sequences of instructions. 
Instead, these generic, compiled functions receive as argu- 
ments the operating parameters of the in-line trigger. Thus, 
in-line triggers operate as modular "templates" in that they 
include all of the code that is common to the normal triggers 
they replace and parameters for receiving values for non- 
common code. Three kinds of operating parameters may be 
passed into an in-line trigger function: trigger- type specific 
parameters, operational metadata, and operational data. 

Trigger-type specific parameters are those parameters that 
are closely related to the purpose for which the trigger was 
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created. For example, the trigger-type specific parameters In-line triggers also enhance database security because 

for a replication trigger specify the destination site of the they use compiled functions. Consequently, it is very diffi- 

replication, the unit of replication (which bodies of data are cult for users to accidentally or intentionally modify the 

replicated together), and administrative information such as in-line instructions and in the process corrupt the database 

whether replication is temporarily suspended. 5 system. 

Operational metadata is information about the body of ^ following description will illustrate in detail the 

data that is being operated upon. For example, operational implementation and operation of in-line triggers in one 

metadata describes the name of the user initiating the dfic environment ^ namely replication triggers that fire 

operation, the nature of the ^operation (insert, delete, remove, whcQ DML statcmcnts arc Hcd t0 databasc 

select) the name of the table upon which a DML statement 10 How mose m me ^ ^ readily recognize that in-line 

is apphed, the owner of the table, a Umestamp mdicaUng m nQ{ ]imitcd tQ ^ cnvironmcnt but m 

when the operation is taking place, and so forth. Operational of a applicabilitv> 
metadata is generally of use for most triggers, even for 

triggers created for quite different purposes. For example, Creating In-line Triggers 

the name of the table is useful for both replication triggers . _ _ . j4 . ... 

, . . . t - A _ i3 With reference to FIG. 2, when a database administrator 

and summary table triggers. , , ... / . , , . . 

~ , . . . - . enables an in -line trigger for a table, the database system 

Operational data is information about the result of apply- 4 c , . . , ' . . . . 

\ . 1 . * « ^ « ti 5 t prompts for and receives information through a user inter- 

mg the operation to a body of data. Specifically, operational r £ %_ , tl , * • /, 

T 6 . f , . u 1 _. i_ 1 face from the admmistrator about the specific trigger (step 

data includes the old values and the new values. For - nfV . „ . , . . ,. , : \. 

t . c Jt .. , r-,*-, 200). For example, if the trigger is a replication trigger, then 

example, if a user updates a value in a column from 1 to 2, on , , r r% . r . L 4 6 L , ' . 

7iT ij V ■ , ™ . * ' 20 the database system prompts for the name of the table being 

the old value is 1 and the new value is 2. . , At _ J « . , r f T t > t . ■ f 

. ,. ... . . , replicated, the kind of the replication, the site to which 

Acmcial aspect to in-line triggers is evident when a single Ucas m d and SQ forth The ific informa . 

command by a user causes the same DML statement to be ^ sied b the database system ^ from in . hnQ 

apphed to a large number of rows of a table. Repeatedly lrf to , ri de ndin on ^ s ecific u ose 

applying the same DML statement to a large number of rows 25 ^ lri gg C r has been coded to perform, 

causes the same trigger to fire repeatedly for each row. . . . . . . c . . . j • • . . 

jl j- 1 ii_ * • * -a t * j j After receiving the information from the administrator, 

Accordingly, Uic tnggcr-type specie parameters are oaded « ^ fafonM|ion „ metadala ^ , 

mto fast, run-time memory the first time a DML statement , t . J ... . . t , / 4 n . 

r j *u * u a *u * • t * j r j 11 ** data orcUo nary withm the database (step 202)/Finally, the 

is apphed that would fire the trigger. Instead of deallocating / a ■ *irTT?~" — 

the memory for those parameters after the trigger bai so-^fff ^ em SS *f ^\^ X 

performed its series of actions, the run-time memory for ^ th f . tablem 1 d f , t0 ^ ale that the 

Lse parameters is maintained for another application of the u, - lme ta S8 er 15 10 fire for ^ ^ ( ste P 204 ); 

DML statement. In order to prevent an excessive amount of Firing An In-line Trigger 

run-time memory being allocated for trigger-type specific 

parameters, the least recently used set of parameters is 35 When a DML statement is applied to a table for which the 

periodically "aged-out" and deallocated. According to one database system fires a trigger, the steps depicted in FIG. 3 

embodiment, the memory for these parameters comprises are executed for in-line triggers during the application of 

part of a "cursor," that is a section of run-time memory that ^at DML statement. In step 300, the database system checks 

is allocated for each DML statement. Cursors comprise a to see if a cursor has already been instantiated for the DML 

parse tree of the DML statement and memory bound vari- aq statement. In one embodiment, DML statements are sped- 

ables aod persist between applications of the same DML fied b V a string containing an SQL instruction. Tins string is 

statement hashed and used to look up a pointer to a cursor in a hash 

™ r ... . «; • * ■ table. If the pointer is found in the hash table, then the cursor 

Therefore, in-line triggers are very efficient in . t _ * . . . . . . ' , . . 

„r _ a u„„„« :„ 1: ™„;f;, n * nmotor i*, 0 A exists. On the other hand, if the pointer is not found, then the 

performance, because in-line triggers specify parameterized , , . , ' .\ . . . ^ ' t , 4 

i_- ! . j -c , cursor does not exist. It is well-known in the art that data 

machine language instructions and the trigger- type specific 45 , L ™ , . 

parameters are loaded once for many firings of the same structurc ^ ^ivalent to hash tables, such as linked hsts 

trigger. The database kernel can be informed of the address iT ™> ™ d arra f m f K bc ? w ^ however hash 

ofthestartofthecompUedfuoctionbyavarietyofmethods. abl ^ s m P referred because of meir P^ormance dunng 

One method, static finking, is to inform the database kernel looKup. 

of the starting address of the function at the time the 50 If tbc cursor docs not exist for ^ c DML statement, then 

compiled object files of the kernel are linked to form an DML statement is parsed and compiled to form a cursor 

executable file. Another method is to inform the database ( ste P 302). Thus, the cursor includes a compiled form of the 

kernel during run-time, such as when the kernel begins DML statement as well as memory for variables used in the 

running; this is called "dynamic linking." Yet another DML statement The invention does not require any parucu- 

method is to inform the database kernel by giving the name 55 lar wa Y t0 P*** and compile DML statements; indeed, a 

of a executable file containing the compiled code. When the variet y of such ways is known in the art. However, the 

database kernel process executes this last form of compiled resulting cursor should include memory or, a reference to 

code, it spawns a new process for executing the function. ^memoryjor trigger-type specific parameters. " 

The particular technique employed for firing an in-line In step 304, a trigger flag ^and trigger-type specific param- 

trigger depends on the environment of the in-line trigger. 60 eters are loaded into the cursor, by calling a call-back 

Static linking is preferred for triggers performing specific ftmction associated with that in-line trigger. Ultimately, 

administrative tasks, such as replication. Spawning a new these parameters come from metadata stored in the data 

process is good for firing a trigger of unverifiable security, dictionary, but a preferred embodiment stores a copy of this 

such as a customer-written trigger, since the operating metadata in a 'library cache" in main memory to improve 

system will provide some isolation between the trigger 65 the performance of loading this metadata, 

process and the database server process of the database After completing the creation of the cursor in steps 302 

system. and 304, or if a cursor was already instantiated for the DML 
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statement, step 306 is performed. At step 306, DML state- trigger places the modification in a deferred transaction 

ment metadata is loaded into run-time memory. At step 308, queue, which is periodically inspected by a dequeue process 

the DML statement is executed and the old values and new for pushing the modification to the replication sites, 

values are determined and loaded. According to one embodiment an in-line asynchronous 

At this point, the database system successively fires each 5 push replication trigger requires such replication-specific 

in-line trigger created for the table by calling the compiled Parameters as the unit of replication and the mimber and 

function (step 310). In one embodiment, the compiled identity of the replicated columns. Asynchronous push rep - 

functions for in-line triggers are statically linked to the hcaUon squires fewer parameters than the synchronous 

database kernel and are therefore always present in the vcrsion > because * c dc( J ucue P roccss handlcs much of ^ 

database system. Accordingly, the fact that an in-line trigger 10 replication functionality. In addition, the replication-specific 

is "created" for a particular table is determined by deter- parameters include such administrative information as 

mining whether a trigger flag (consisting of one bit in the whether replication is turned off or temporarily suspended, 

metadata for the table) is enabled. The operation of such an ^ non-repUcation-specific information required by this 

embodiment is described in more detail hereafter. In another m ' lme transaction identifiers the name of 

embodiment, me database system maintains a list of pointers 15 the user the name and owner of the modified table, the 

to the in-line trigger compiled functions and the trigger- names of the columns, their old values, their new values, and 
specific parameter loading call-back functions. When steps 

their types. 

304 and 310 arc performed, the database system simply since both forms of P^ replication require much the 

steps through this list executing each trigger-specific param- same parameters, a preferred embodiment of the invention 

eter loading call-back function and trigger compiled M combines the instructions for the two in-line triggers into a 

function, respectively. After all the triggers associated with generic in-line push trigger. Accordingly, that in-line trigger 

the table have fired, processing the DML statement is * P 3 ^ parameters required by both types and an addi- 

complete. tional parameter that indicates whether asynchronous repli- 
cation is requested. In addition, since push replication may 

In-line Triggers for Replication 25 be turned off or suspended, a preferred embodiment loads 

~ . .... . . ,. . , . , the administrative information whether push replication is 

Data replication is one environment in which a database - A . . 4 , - ... r . *, f 

, 1 r< o . # . ^ „ . . active for the site before loading the remainder of the 

system employs a plurality of in-line triggers. Determining 4 c iL , . * . . . . iL r 

J ■ j £. * * r . • 1 r * • j j parameters for the trigger. In this situation, the preferred 

the number and functionality or each in-line trigger depends r . ,. , -j ^ • * . • 

A , i 4l _ j . r embodiment avoids an unnecessary firing of a trigger, 

on a careful consideration of the purpose and parameters for , , , , , 3 & , . 

each in-line trigger. First, an overview will be made of the 30 . ^ J"* 1 model changes are propagated to a rephcation 

various types of replication that can be implemented with s ! te ^request of the database system of the replication 

in-line triggers and some of their required parameters. After Slte ' 0nc implementation of the pull model is a snapshot of 

this overview, the operation of an embodiment of the inven- a paster table. A snapshot is a consistent view of the master 

tion implementing multiple in-line triggers for replication table > ^ mch m ^ be ^freshed to provide another consistent 

will be discussed 35 view ' Changes to a master table are stored in a snapshot log 

until a snapshot using that table requests a refresh operation. 

Replication Parameters for In-line Triggers In response to the refresh operation, entries stored in the 

„ snapshot log are propagated to the snapshot. The in-line 

Data rephcation can follow one of two models in propa- triggef that stores such eQtries m ^ snapshot ^ 

gating changes from one site to another: a "push" model and 40 herein an « in . line master pull triggen " 

a "puir model. In the push model, changes are propagated A j. 4 . j- * 1* * n 

A "T .... . A * . , * r , . , , According to one embodiment, an in-line master pull 

to the replication sites at the request of the site at which the . . ,. 4 . c , \. 

. r l jij. i- trigger requires such replication-specific parameters as the 

changes were made. In the push model, data replication can ^ rf ^ ^ * ^ J^. ^ ^ Qf ^ 

be other synchronous or asynchronous. Synchronous repli- bei re H ]icated f ^ how rows m the master uble 

cation maintains multiple copies ; of the same data and 45 afe ^ non-specifk-replication parameters for 

guarantees dial each copy of the data is identical within a ^ m _ line , rf inchlde , he old ootomn val the Qew 

disputed database system. To ensure ths guarantee, the cohmn ya] ^ of ^ ^ ^ ^ jdentifler of 

rephcation is treated as part of a transaction that performs an A . a A 

+ » j- 1 *t_ j . l , * . m * the modined row. 

update. Accordingly, the database system at the site of the A . . 

modification does not consider the transaction complete 50 g H en J bod / men ^ * K s ? a P shot 5" be 

until all of the replicas are updated by a two-phase commit. ^ blt 50 ^ a '°,^ e u P^ atable ""P* 01 are 

, . . stored in an updatable snapshot log and propagated back to 

According to one embodiment, an in-line trigger for me fflaster ^ „ fefresh lime In ^ m .^.^ 

performing synchronous push replication requires snapsh ot pu n trigger" stores those changes in the updatable 

replication-specific parameters such as the unit of s ho , to ^ trf ^ such KpUcition . 

replication, the number and identity of the replicated 55 specific parameters as the name of the updatable snapshot 

columns, and a list of the sites containing the replicas. In { me nunjber ^ idemi of ffle bej licated> 

addiuon, the rcphcaUon-spccific parameters include such ^ how rows m ^ master ub , e are idemified . ^ non . 

admm-strauve information as whether rephcation is turned S p eciflc . replicaaorj parameters for the in-line trigger include 

off or temporary suspended. The non-replicaUon-specmc me M mlumQ vil me new vaJu ^ of 

informauon required by this m-hne trigger includes trans- „ ^ ch and ^ identifier of , he modified row 
action identifiers, the name of the user, the name and owner 

of the modified Uble, the names of the columns, their old Multiple In-line Triggers 
values, their new values, and their types. For some databases, various replication schemes are sup- 
Asynchronous replication, on the other hand, updates the ported simultaneously. Accordingly, an embodiment for 
replicas without respect to when the transaction performing 65 such databases employs multiple in-line triggers. Each spe- 
the updates is completed, allowing the user to continue cific in-line trigger has a specific trigger flag, which is 
working with the local database sooner. An asynchronous examined by the database system in sequence. 
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Referring to FIG . 4, the operation of firing multiple in-line 
triggers for replication triggers is illustrated . It is assume that 
before performing step 310, which comprises steps 410 to 
436, step 304 was performed at some point in the past, either 
during the application of the current DML statement or a 5 
prior DML statement. Step 304 ensures that the trigger flag 
and other trigger-type specific parameters are loaded into 
run-time memory, preferably as designated bits of a single 
machine word. 

Thus, before step 410 is performed, a plurality of trigger ™ 
enable flags has been loaded. The bit designated as the 
in-line push trigger flag is examined (step 410). If the push 
trigger flag is not enabled, execution skips to step 420. 

On the other hand, if the push trigger enable flag is indeed 
enabled, then the database system calls the compiled code 15 
for the in-line push trigger with the trigger-type specific 
parameters, the operation metadata, and the operational data 
on each row (step 416), and execution proceeds to step 420. 

At step 420, the bit designated as the master pull trigger 
flag is examined. If the master trigger flag is not enabled, 
execution skips to step 430. On the other hand, if the master 
pull trigger flag is indeed enabled, then the database system 
calls the compiled code for the in-line master pull trigger 
with the trigger-type specific parameters, the operation 
metadata, and the operational data on each row (step 426), 25 
and execution proceeds to step 430. 

At step 430, the bit designated as the snapshot pull trigger 
flag is examined. If the snapshot pull trigger flag is not 
enabled, execution returns control to the database system. 3fl 
On the other hand, if the snapshot pull trigger flag is indeed 
enabled, then the database system calls the compiled code 
for the in-line snapshot pull trigger with the trigger-type 
specific parameters, the operation metadata, and the opera- 
tional data on each row (step 436). Afterwards, execution 35 
returns back to the database system. 

By providing a plurality of in-line trigger flags for a 
plurality of in-line triggers, a database system can support a 
variety of data replication protocols without having the 
drawbacks associated with the proliferation of conventional 40 
triggers. In specific, the memory requirement of in-line 
triggers is much less than that of conventional triggers, 
because only one copy of a trigger is stored at each site per 
replication protocol, rather than per replicated object and 
protocol. Since in-line triggers are table -independent, they 45 
can be written in advance in a compiled programming 
language like C for high-performance execution. 
Furthermore, compiled in-line triggers can be stored inside 
the database kernel and are hence more secure than conven- 
tional triggers stored as an object in the database. 



In-line Summary Table Triggers 



so 



While the present invention of in-line triggers has been 
described with respect to a replication environment, the 
present invention may apply to other environments. For 55 
instance, the present invention also applies to summary 
tables. A summary table indexes key values that are based on 
values contained in one or columns of a base table. For 
example, a base table has a column with extensive textual 
data, such as a document. A summary table based on that 60 
base table may contain a list of which keywords are found 
in the textual data of which rows. 

To illustrate, suppose the base table has a column for 
American historical document. Row 1 contains the Decla- 
ration of Independence, row 2 contains the federal 65 
Constitution, and row 3 contains the Gettysburg Address. A 
summary table based on this base table would contain an 



entry that states that the key value "president" is found in 
row 2 and another entry that states that the key value 
"liberty'* is found in row 1, 2, and 3. In this example, the key 
values are derived from the column values by extracting 
substrings; however, summary table key values may be 
based on a mathematical relationship applied to a column 
value or to the values of several columns. 

When a user modifies a base table, the summary table 
may, then, become out of date with respect to the base table. 
Accordingly, one way to bring summary tables up to date 
would be to inform a process that is responsible for 
maintaining, updating, or creating the summary table about 
the modification. In-line triggers, since they are fired upon a 
modification of table data, are used to queue information 
about changed base tables so that summary tables may be 
eventually brought up-to-date. 

In the foregoing specification, the invention has been 
described with reference to specific embodiments thereof It 
will be evident, however, that various modifications and 
changes may be made thereto without departing from the 
broader spirit and scope of the invention. The specification 
and drawings are, accordingly, to be regarded in an illus- 
trative rather than a restrictive sense. 

What is claimed is: 

1. A method for applying an operation to a body of data, 
said method comprising the computer-implemented steps of: 

determining whether there is a section of run- time 
memory associated with said operation, wherein said 
section of run-time memory comprises a compiled form 
of said operation and trigger-type specific parameters 
loaded from trigger-type specific data specified by a 
trigger defined for firing when said operation is applied 
to said body of data to cause a series of actions to be 
performed; 

if there is not a section of run-time memory associated 
with said operation, then performing the steps of: 
compiling said operation into said compiled form, and 
loading said trigger-type specific data as said trigger- 
type specific parameters; 

loading operational metadata that describes said body of 
data; 

applying said operation to said body of data; 

loading operational data that describes the effect of apply- 
ing said operation; 

causing said series of actions to be performed based on 
said trigger-type specific parameters, said operational 
metadata and said operational data. 

2. The method of claim 1, wherein the step of causing a 
series of actions to be performed includes the step of causing 
said operation to be asynchronously replicated at a copy of 
said body of data. 

3. The method of claim 1, wherein the step of causing a 
series of actions to be performed includes the step of causing 
said operation to be synchronously replicated at a second 
copy of said body of data. 

4. The method of claim 1, wherein the step of causing a 
series of actions to be performed includes the step of causing 
said operation to be asynchronously replicated at a first copy 
of said body of data and synchronously replicated at a 
second copy of said body of data. 

5. The method of claim 1, wherein the step of causing a 
series of actions to be performed includes the step of causing 
said operation to be reflected in a summary table. 

6. The method of claim 1, further comprising the step of 
defining the trigger for firing when said operation is applied 
to the said of data, wherein the trigger specifies the series of 
actions and the trigger-type specific data. 
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7. The meihod of claim 6, wherein the step of defining the 
trigger for firing when said operation is applied to said body 
of data includes the step of defining the trigger for firing 
when a DML statement is applied to a row of a table. 

8. The method of claim 6, wherein the step of defining the 
trigger for firing when said operation is applied to said body 
of data includes the steps of: 

receiving said trigger-type specific data as input from a 
user; and 

storing said trigger-type specific data as metadata associ- 
ated with said trigger. 

9. The method of claim 6, wherein: 

the step of defining the trigger includes the step of storing 
a first reference to first instructions for causing said 
series of actions to be performed; and 

the step of causing said series of actions to be performed 
based on said trigger-type specific parameters, said 
operational metadata, and said operational data 
includes the step of executing said first instructions 
based on said first reference with said trigger-type 
specific parameters, said operational metadata, and said 
operational data passed as parameters. 

10. The method of claim 9, wherein: 

the step of defining a trigger for firing when said operation 
is applied to said body of data includes the step of 
storing a second reference to second instructions for 

loading trigger- type specific data into run-time 

memory; and 

the step of loading trigger-type specific data as said 
trigger-type specific parameters includes the step of 
executing said second instructions based on said second 
reference. 

11. The method of claim 9, wherein 

the step of storing a first reference to first instructions 
includes the step of statically linking said first instruc- 
tions to a database kernel. 

12. The method of claim 9 ; wherein 

the step of storing a first reference to first instructions 
includes the step of dynamically linking said first 
instructions to a database kernel. 

13. The method of claim 9, wherein 

the step of storing a first reference to first instructions 
includes the step of storing the name of a first execut- 
able file comprising said first instructions. 

14. A computer system, comprising: 
one or more modular compiled triggers; 

a memory for storing trigger flags associated with a body 
of data for enabling one or more respective triggers 
from among the one or more modular compiled trig- 
gers: and 

a database kernel configured to conditionally invoke, 
based on the trigger flags, said one or more respective 
triggers in response to a database event for the body of 
data. 

15. The computer system of claim 14, wherein said 
database kernel is configured to invoke said one or more 
modular compiled triggers in response to receiving a request 
to perform a data manipulation language (DML) operation 
on the body of data. 

16. The computer system of claim 15, further comprising: 
a section of run-time memory for storing trigger-type 

specific parameters; and 
means for passing said trigger-type specific parameters to 
a modular compiled trigger associated with said DML 
operation when invoking said modular compiled trig- 
ger. 
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17. The computer system of claim 16, wherein said one or 
more modular compiled triggers include a plurality of modu- 
lar compiled replication triggers, wherein the modular com- 
piled replication triggers, when invoked, cause a change 

s made to a first copy of the body of data to be propagated to 
a second copy of the body of data. 

18. A computer readable medium having stored thereon 
sequences of instructions for applying an operation to a body 
of data, said sequences of instructions including sequences 

10 of instructions for performing the steps of: 

determining whether there is a section of run-time 
memory associated with said operation, wherein said 
section of run-time memory comprises a compiled form 
of said operation and trigger-type specific parameters 

35 loaded from trigger-type specific data specified by a 
trigger defined for firing when said operation is applied 
to said body of data to cause a series of actions to be 
performed; 

if there is not a section of run-time memory associated 
20 with said operation, then performing the steps of: 

compiling said operation into said compiled form, and 
loading said trigger-type specific data as said trigger- 
type specific parameters; 
loading operational metadata that describes said body of 
25 data; 

applying said operation to said body of data; 
loading operational data that describes the effect of apply- 
ing said operation; 
30 causing said series of actions to be performed based on 
said trigger- type specific parameters, said operational 
metadata and said operational data. 

19. The computer readable medium of claim 18, wherein 
causing a series of actions to be performed includes the step 

35 of causing said operation to be asynchronously replicated at 
a copy of said body of data. 

20. The computer readable medium of claim 18, wherein 
the step of causing a series of actions to be performed 
includes the step of causing said operation to be synchro- 

40 nously replicated at a second copy of said body of data. 

21. The computer readable medium of claim 18, wherein 
the step of causing a series of actions to be performed 
includes the step of causing said operation to be asynchro- 
nously replicated at a first copy of said body of data and 

45 synchronously replicated at a second copy of said body of 
data. 

22. The computer readable medium of claim 21, wherein 
the step of causing a series of actions to be performed 
includes the step of causing said operation to be reflected in 

50 a summary table. 

23. The computer readable medium of claim 18, wherein 
said sequences of instructions further comprise sequences of 
instructions for performing the step of defining the trigger 
for firing when said operation is applied to the said of data, 

55 wherein the trigger specifies the series of actions and the 
trigger-type specific data. 

24. The computer readable medium of claim 23, wherein: 
the step of defining the trigger includes the step of storing 

a first reference to first instructions for causing said 

60 series of actions to be performed; and 

the step of causing said series of actions to be performed 
based on said trigger-type specific parameters, said 
operational metadata, and said operational data 
includes the step of executing said first instructions 

65 based on said first reference with said trigger-type 
specific parameters, said operational metadata, and said 
operational data passed as parameters. 
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25. The computer readable medium of claim 23, wherein 
the step defining the trigger for firing when said operation is 
applied to said body of data includes the step of defining the 
trigger for firing when a DML statement is applied to a row 
of a table. 

26. The computer readable medium of claim 23, wherein 
the step of defining the trigger for firing when said operation 
is applied to said body of data includes the steps of: 

receiving said trigger-type specific data as input from a 
user; and 

storing said trigger-type specific data as metadata associ- 
ated with said trigger. 

27. The computer readable medium of claim 9, wherein 
the step of storing a first reference to first instructions 

includes the step of storing the name of a first execut- 
able file comprising said first instructions. 

28. The computer readable medium of claim 24, wherein 
the step of storing a first reference to first instructions 
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includes the step of statically linking said first instructions to 
a database kernel. 

29. The computer readable medium of claim 24, wherein 
the step of storing a first reference to first instructions 

5 includes the step of dynamically linking said first instruc- 
tions to a database kernel. 

30. The computer readable medium of claim 24, wherein: 
the step of defining a trigger for firing when said operation 

is applied to said body of data includes the step of 
10 storing a second reference to second instructions for 
loading trigger-type specific data into run-time 
memory; and 

the step of loading trigger-type specific data as said 
15 trigger-type specific parameters includes the step of 
executing said second instructions based on said second 
reference. 
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